src/renderer/features/activity/FileTreeMenu.tsx (3)

85-121: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Menu can render off-screen near viewport edges.

positioned places the menu at the raw clientX/clientY with no clamping against window.innerWidth/innerHeight. Right-clicking near the right or bottom edge of the window can push menu items (especially the wider 224px w-56 edit panel) partially or fully off-screen and unreachable.

Consider clamping the coordinates (either with an estimated width/height, or by measuring the rendered menu via ref + useLayoutEffect and repositioning once mounted).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/renderer/features/activity/FileTreeMenu.tsx` around lines 85 - 121, The
context menu positioning in FileTreeMenu is using raw point.x/point.y, so the
menu can render off-screen near the right or bottom viewport edges. Update the
positioning logic around the positioned value in FileTreeMenu to clamp the
coordinates against window.innerWidth and window.innerHeight, or measure the
rendered menu through ref with useLayoutEffect and adjust after mount. Make sure
both the edit panel and the normal menu stay fully visible when opened near the
viewport boundaries.

---

116-216: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Menu lacks ARIA menu semantics.

The dropdown and its items are plain div/button elements with no role="menu"/role="menuitem", and no item receives focus when the menu opens (only the rename/create input auto-focuses). Adding basic ARIA roles (and optionally auto-focusing the first item) would improve screen-reader and keyboard support for this new interactive surface.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/renderer/features/activity/FileTreeMenu.tsx` around lines 116 - 216, The
FileTreeMenu dropdown currently renders as plain container/button markup without
menu semantics, so update the root menu wrapper and MenuItem in FileTreeMenu to
use proper ARIA roles (menu/menuitem) and keyboard-friendly focus behavior. Add
the relevant role attributes and ensure an item is focusable or auto-focused
when the menu opens, especially for the non-editing actions like Reveal in
Explorer, Copy path, and Delete, so the menu is accessible without relying only
on the rename/create inputs.

---

31-36: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Validation/path logic lives directly in a presentational component.

isValidName and the path-composition logic in commit() are domain/business logic embedded in a feature component file. As per path instructions for src/renderer/features/**/!(*.test).{ts,tsx}: "Keep renderer components presentational: components should not contain business logic; use feature folders plus stores for domain behavior." Moving isValidName (and ideally the target-path computation) into a shared lib (e.g. alongside fileIcons.tsx) or into useFileSystemStore would keep this component focused on rendering/interaction and make the validation reusable/testable independently.

Also applies to: 64-83

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/renderer/features/activity/FileTreeMenu.tsx` around lines 31 - 36, Move
the name validation and target-path construction out of FileTreeMenu into domain
logic, since this component currently mixes presentation with business rules.
Extract isValidName and the commit() path-composition behavior into a shared
helper or useFileSystemStore, keeping FileTreeMenu focused on rendering and user
interaction. Use the existing symbols isValidName and commit() as the main entry
points when relocating the logic so the component stays thin and the rules
become reusable/testable.

Source: Path instructions

src/renderer/stores/useFileSystemStore.ts (1)

98-121: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider consolidating the repeated api-guard boilerplate.

createFile, createDir, remove, and rename all repeat the identical const api = fsApi(); if (!api) return false; guard before delegating to runMutation. A small helper (e.g. withApi(fn, label) that resolves the api once and wraps the call) would remove the duplication and reduce the chance of one method drifting from the pattern later.

♻️ Example consolidation

+async function guardedMutation(
+  op: (api: NonNullable<ReturnType<typeof fsApi>>) => Promise<unknown>,
+  label: string,
+): Promise<boolean> {
+  const api = fsApi();
+  if (!api) return false;
+  return runMutation(() => op(api), label);
+}
+
   createFile: async (workspaceId, relPath) => {
-    const api = fsApi();
-    if (!api) return false;
-    return runMutation(() => api.createFile(workspaceId, relPath), 'Could not create file');
+    return guardedMutation((api) => api.createFile(workspaceId, relPath), 'Could not create file');
   },

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/renderer/stores/useFileSystemStore.ts` around lines 98 - 121, The methods
createFile, createDir, remove, and rename in useFileSystemStore all repeat the
same fsApi() null-check before calling runMutation. Extract that shared guard
into a small helper such as withApi(fn, label) or similar, then have each method
delegate through it so the api is resolved once and the mutation/error-label
pattern stays consistent across these operations.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes